今後のLambdaの機能拡張に対する要望を挙げてみた – AWS Lambda Advent Calendar 2014:7日目
ウィスキー、シガー、パイプをこよなく愛する大栗です。 本エントリはAWS Lambdaに関するアドベントカレンダー『AWS Lambda Advent Calendar 2014』の7日目の内容となります。
はじめに
現在LambdaはPreviewとして公開されており、Previewに申し込んだユーザのみに限定公開されています。Previewの意味を辞書で引くと試写会とか予告編と出ています。 そのため正式公開に向けて、ユーザが参加するテストや今後のアップデート内容を検討するためと考えられます。それでは今後アップデートで採用してもらいたい機能を挙げてみたいと思います。
SNS連携の対応
大半の方が、対応していないのか?と言いそうですが、現在はSNSからLambdaを起動する事はできません。早くSNSからLambda実行が可能になってほしいです。SNSからLambdaを起動できたり、Lambdaの実行結果をSNSで通知したりできてほしいと思います。 SNSから起動できたりLambdaの結果をSNSで通知可能になると、Lambdaを使って独自の通知を実装したり、SNSを使ってLambdaを複数個繋げる事ができる様になります。
例えばTwilioを連携させる事で電話通知も可能になります。また、LambdaをSNSで接続する事でCDPのQueuing Chainパターンの様に簡単なワークフローが実装可能になります
外部のhttpアクセスの受信イベントに対応
現在はS3、DynamoDB、Kinesisのみが対応しており、今後は他のサービスも対応すると考えられます。AWSのイベントに反応して処理を行えますが、外部からのhttpアクセスを受信するイベントが対応できるとAWS以外のサービスと連携可能になります。Elastic Beanstalkでマネージドに対応可能ですが、もっと抽象化された機能として実装してほしいです。
例えばgtihubのWebhookやSendGridのParse Webhookとの連携が、マネージドサービスのみで行える様になります。
複数イベント出力の対応
S3で同じイベントを重複して出力しようとすると、以下のエラーメッセージ出力されます。これが複数のLambda functionやSNS Topic、SQS Topicへ出力できると自由度が増すと考えています。
例えば、Lambda functionとSQSへ出力できると、昨年から注目を浴びているラムダアーキテクチャが実現できます。(同じ名前ですが別の物です) ラムダアーキテクチャとは大規模データを処理するアーキテクチャの一種で、データ処理をストリーム処理(speed layer)とバッチ処理(batch layer)で融合させる考え方です。
詳しくは以下のウェブサイト等を参考にして下さい。
現在の機能でもLambda function内でSQSへメッセージを送れば同様の事ができるのできますが、イベントを複数個出力できればすっきりと実装する事が可能になります。
さいごに
AWSのアップデートは加速度的に増加しているので、あまり間を置かずにこれらの要望を対応してくれると信じています。
なお、投稿日を見ると分かるのですが12月8日に投稿しています。Node初心者のため全く検証コードが動かず時間を浪費してしまったため、内容を変更して上記となりました。 UTCで12月7日ということで勘弁して下さい。ごめんなさい。